TITLE OF THE INVENTION 
METHOD, PROGRAM, AND STORAGE MEDIUM FOR ACQUIRING LOGS 



FIELD OF THE INVENTION 
5 The present invention relates to a technology for 

acquiring processing logs for software consisting of a 
plurality of modules. 



BACKGROUND OF THE INVENTION 
10 Software failure that does not repeatedly occur 

has been solved by acquiring and analyzing the 
processing log of the software to identify the cause of 
the failures. 

Processing log acquisition according to such 
15 prior-art methods has the following problems: 

(1) Software modules must be modified to add a routine 
for acquiring a process log. Accordingly, the workload 
for acquiring the process log is heavy. 

(2) Processing log acquisition is performed for each 

20 module and therefore logs are generated on a module-by- 
module basis. It is difficult to obtain a 
chronological log of entire software processing. 
Consequently, a large number of man-hours are required 
for analyzing a log to identify the cause of a failure 

25 because it does not provide a broad view of the entire 
processing . 
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SUMMARY OF THE INVENTION 
The present invention has been made to solve the 
problems described above. An object of the present 
invention is to provide a method that allows a log of a 
5 software program separated into modules to be readily 
obtained and reduces the number of man-hours needed to 
analyze the cause of software failure, a program for 
causing a computer to perform the method, and a storage 
medium containing the program. 

10 To achieve the object, the present invention 

provides a log acquisition method for acquiring a 
runtime log of a program including a function for 
performing a predetermined process, comprising the step 
of: changing the address of the function loaded for 

15 performing the predetermined process to the address of 
a function for log acquisition, wherein the function 
for log acquisition comprises the steps of: calling the 
function for performing the predetermined process to 
cause the predetermined process to be executed, 

20 receiving the result of the execution, and passing the 
result to the program; determining whether or not a 
pointer parameter is defined in a predetermined manner 
in a function definition in the program; and if the 
pointer parameter is defined in the predetermined 

25 manner, recording a memory content pointed to by the 

pointer parameter as a log according to the definition. 
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To achieve the object described above, the present 
invention provides a log acquisition method for 
obtaining a runtime log of a program including a 
function for performing a predetermined process, 
5 comprising the steps of: 

changing the address of the function loaded for 
performing the predetermined process to the address of 
a function for log acquisition; and 

selecting the function for log acquisition; 
10 wherein the function for log acquisition comprises the 
steps of: calling the function for performing the 
predetermined process to cause the process to be 
executed, receiving the result of the execution, and 
passing the result to the program; recording given 
15 information as a log when calling the function selected 
in the selecting step; and recording given information 
as a log when receiving the result of execution of the 
function selected in the selecting step. 

Other features and advantages of the present 
20 invention will be apparent from the following 

description taken in conjunction with the accompanying 
drawings, in which like reference characters designate 
the same or similar parts throughout the figures 
thereof . 

25 

BRIEF DESCRIPTION OF THE DRAWINGS 
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The accompanying drawings, which are incorporated 
in and constitute a part of the specification, 
illustrate embodiments of the invention and, together 
with the description, serve to explain the principles 
5 of the invention. 

FIG . 1 shows a configuration of a computer 
(software evaluation system) for implementing a method 
for acquiring logs according to a first embodiment; 

FIG- 2 shows an ordinary organization of memory 
10 in which functions are loaded according to the first 
embodiment; 

FIG. 3 shows an organization of the memory while 
using I AT Patch according to the first embodiment; 

FIG. 4A shows the process while using the IAT 
15 Patch according to the first embodiment; 

FIG . 4B shows a flowchart of a process for 
acquiring a log according to the first embodiment; 

FIG. 5 shows an internal configuration while using 
the IAT Patch according to the first embodiment; 
20 FIG. 6 shows an ordinary memory organization while 

an instance of COM server interface is generating 
according to the first embodiment; 

FIG. 7 shows a memory organization according to 
the first embodiment while using VTable Patch; 
25 FIG. 8A shows the process while using the VTable 

Patch according to the first embodiment; 
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FIG. 8B shows a flowchart of a process for 
acquiring log according to the first embodiment; 

FIG. 9 shows an internal configuration of the 
software evaluation system according to the first 
5 embodiment; 

FIG. 10 shows an example of a function definition 
according to a second embodiment; 

FIG. 11 shows a description written in IDL for 
acquiring pointer parameter data entities as a log 
10 according to the second embodiment; 

FIG . 12 shows a flowchart of a process for 
acquiring a log according to the second embodiment; 

FIG. 13 shows log data obtained according to the 
second embodiment; 
15 FIG. 14 shows a description in function definition 

written in IDL for obtaining a function such as a 
callback function that are not exported according to a 
third embodiment; 

FIG. 15 shows a memory organization according to 
20 the third embodiment; 

FIG. 16 shows a flowchart of a process for 
acquiring a log according to the third embodiment; 

FIG. 17 shows log data obtained according to the 
third embodiment without the definition shown in FIG. 
25 14; 
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FIG. 18 shows log data obtained according to the 
third embodiment through the use of the definition 
shown in FIG. 14; 

FIG. 19 shows a description written in IDL for 
5 obtaining a variable length array parameter as a log in 
a function definition according to a fourth embodiment; 

FIG. 20 shows a flowchart of a process for 
acquiring a log according to the fourth embodiment with 
the function defined as shown in FIG. 19; 
10 FIG. 21 shows log data (250) obtained according to 

the fourth embodiment; 

FIG. 22 shows an example of the functions the 
parameters of which cannot be obtained with an ordinary 
function definition; 
15 FIG. 23 shows how structures use memory; 

FIG. 24 shows a description in IDL for acquiring a 
log of function parameters shown in FIG. 22 according 
to a fifth embodiment; 

FIG. 25 shows a flowchart of a process for 
20 acquiring a log according to the fifth embodiment; 

FIG. 26 shows details of structure parameter 
analysis which are depicted according to memory 
location; 

FIG. 27 shows log data obtained according to the 
25 fifth embodiment; 
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FIG. 28 shows an example of the functions the 
parameters of which cannot be obtained with an ordinary 
function definition according to a sixth embodiment; 

FIG. 29 shows how structures are located in 
5 memory; 

FIG. 30 shows a description in IDL for acquiring a 
log of the function parameters shown in FIG. 28 
according to the sixth embodiment; 

FIG. 31 shows a flowchart of a process for 
10 acquiring a log according to the sixth embodiment; 

FIG. 32 shows log data obtained with the 
definition shown in FIG. 30 according to the sixth 
embodiment; 

FIG. 33 shows a user interface for setting a 
15 function/method initiating a log acquisition process 
according to a seventh embodiment; 

FIG. 34 shows a flowchart of a process for 
acquiring a log according to the seventh embodiment; 
FIG. 35 shows a user interface for setting a 
20 function/method stopping log acquisition according to 
an eighth embodiment; 

FIG. 36 shows a flowchart of a process for 
obtaining a log according to the eighth embodiment; 

FIG. 37 shows a user interface to which a setting 
25 is added for using a trigger function in the event of 
abnormal end according to a ninth embodiment; 
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FIG. 38 shows error definitions for 
functions/methods according to the ninth embodiment; 

FIG. 39 shows a flowchart of a process for 
obtaining a log according to the ninth embodiment; 
5 FIG. 40 is a flowchart showing details of the 

ordinary log acquisition process according to the ninth 
embodiment; 

FIG. 41 shows a flowchart of a process for 
obtaining a log according to the ninth embodiment; 
10 FIG. 42 shows a user interface displaying a tree 

view of interfaces and methods according to a tenth 
embodiment; 

FIG. 4 3 shows a flowchart of a process for 
acquiring a log according to the tenth embodiment; 
15 FIG. 44 shows a user interface displaying a tree 

view of interfaces and methods according to an eleventh 
embodiment; 

FIG. 45 shows a flowchart of a process for 
acquiring a log according to the eleventh embodiment; 
20 FIG. 46 shows a flowchart of a process for 

dividing and storing a log on a date-by-date basis 
according to a twelfth embodiment; 

FIG. 47 shows a flowchart of a process for 
dividing and storing a log according to the size or 
25 number of log files according to a thirteenth 
embodiment ; 
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FIG. 48 schematically shows memory storing a 
predetermined number of logs from among the logs 
obtained in according to a fourteenth embodiment; and 

FIG. 49 shows a flowchart of a process for 
5 acquiring the predetermined number of logs from among 
the logs obtained according to the fourteenth 
embodiment . 



DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
10 Preferred embodiments of the present invention 

will now be described in detail in accordance with the 
accompanying drawings . 
[First Embodiment] 

In a first embodiment, an import function or 
15 virtual address table contained in memory, which is an 
arrangement for calling a function in a module from 
another module, is used to hook and log function calls 
between modules, thereby enabling a chronological log 
of an entire software program to be acquired without 
20 any modifications to the software modules. The first 
embodiment will be described below in detail. 
System configuration 

FIG. 1 shows a configuration of a computer 
(software evaluation system) performing a log 
25 acquisition method according to embodiments of the 
present invention. For simplicity, it is assumed 
herein that the software evaluation system is built 



within a single personal computer. However, the 
features of the log acquisition method of the present 
invention is effective whether the system is built in a 
single PC or a plurality of PCs as a network system. 
5 The computer in which the software evaluation 

system is provided comprises a CPU 1, a chip set 2, a 
RAM 3, a hard disk controller 4, a display controller 5, 
a hard disk drive 6, a CD-ROM drive 7, and a display 8. 
It also comprises a signal line 11 connecting the CPU 1 

10 with the chip set 2, a signal line 12 connecting the 
chip set 2 with the RAM 3, a peripheral bus 13 
connecting the chip set 2 with peripheral devices, a 
signal line 14 connecting the hard disk controller 4 
with the hard disk drive 6, a signal line 15 connecting 

15 the hard disk controller 4 with the CD-ROM drive 7, and 
a signal line 16 connecting the display controller 5 
with the display 8. 

Acquisition of log concerning function process 

In order to facilitate the understanding of the 

20 software evaluation system that implements the log 

acquisition method according to the first embodiment of 
the present invention, how a software program separated 
into a plurality of modules is ordinarily loaded in a 
memory will first be described with reference to FIG. 2. 

25 A software program consisting of modules in 

general is separated into a set of executable files EXE 
(23) and a set of dynamic link libraries DLL (27) 
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existing as modules and serving as a complement to the 
EXE. The EXE consists of a code segment (28), a data 
segment (29), and an import function address table (22). 
The import function table is further divided into DLLs 
5 (21, 24) to which functions belong. Each DLL contains 
addresses (30 to 35) at which each function is loaded. 
The contents of the functions of each DLL are 
separately loaded (25, 26) and each function (36 to 41) 
is loaded as part of the associated DLL. FIG. 2 shows 

10 an example in which one EXE uses the functions in two 

dynamic link libraries, A. DLL and B.DLL. Six functions, 
Func AA, Func AB, Func AC, Func BA, Func BB, and Func 
BC are used. 

When a code in a code segment of the EXE calls 

15 function Func AA, the address (30) of Func AA written 

in the import function address table is first read. In 
effect, the address of AA code (36) read as part of 
A. DLL is written here. The code of the EXE can call 
Func AA of A. DLL by calling the address of the AA code 

20 (36). 

FIG. 3 shows an organization of the memory 
according to the first embodiment. This organization 
differs from the one shown in FIG. 2 in that a 
technology called IAT Patch (Import Address Table 
25 Patch) is used with log acquisition codes to redirect 
function calls. 
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When log acquisition is initiated, C.DLL (58), 
which is a DLL for the I AT Patch is loaded in the 
memory. C.DLL changes the addresses of functions 
written in the import function address table (52) to 
5 the addresses (61 to 66) of log acquisition codes, Func 
CAA, Func CAB, Func CAC, Func CBA, Func CBB, and Func 
CBC, in C.DLL. The codes Func CAA, Func CAB, Func CAC, 
Func CBA, Func CBB, and Func CBC in C.DLL (73 to 78) 
perform logging and calls the corresponding functions, 

10 Func AA, Func AB, Func AC, Func BA, Func BB, and Func 
BC (67 to 72) loaded in the memory for responding to 
the function calls. 

FIG. 4A shows an I AT Patch process performed in 
the example shown in FIG. 3. FIG. 4B is a flowchart of 

15 a log acquisition process. For simplicity, the figures 
show how the log acquisition code works with IAT Patch 
when the EXE calls Func AA in A. DLL. 

When the EXE (91) calls Func AA (94), the log 
acquisition code in C.DLL stores the DLL name/function 

20 name (step S402), the call time, and parameter used in 
the call in the memory and stores the memory content 
pointed to by a pointer parameter used in the call in 
another memory (95 and step S403). C.DLL then calls 
Func AA in A. DLL (93), which is intended to be called 

25 (96 and step S404) . When the Func AA process (96) in 

A. DLL ends and control is returned to C.DLL (98), C.DLL 
stores the return time and return value in memory and 
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stores the memory content pointed to by the pointer 
parameter in the return in another memory. Then C . DLL 
writes the log information it has stored into a file 
(100 and step S405) . The control then returns to the 
5 EXE as if Func AA in A. DLL was completed in a 
conventional way (101) . 

FIG. 5 shows an internal configuration of the 
software evaluation system that implements the log 
acquisition method according to the first embodiment. 

10 Conventionally, an executable EXE (113) calls a 

function in DLL-1 (116) or DLL-2 (117) . In this method, 
in contrast, a log acquisition code called an API 
tracer (114) is embedded to generate a processing log 
(115). The API tracer (114) operates according to a 

15 file (111) that describes definitions of functions in 
DLL-1 or DLL-2 and a setting scenario (trace scenario) 
that specifies which function in which DLL in an import 
function table should be rewritten to obtain a log. 
Acquisition of log concerning method process 

20 Described below is how an executable file EXE 

(113) is loaded in a memory in the software evaluation 
system implementing the log acquisition method 
according to the first embodiment when an instance of 
an interface exported in a COM (Component Object Model) 

25 server. In order to explain this, how it is ordinarily 
loaded will first be described in FIG. 6. 
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When an instance of an interface is generated, the 
requested interface (121, 122) and its methods (130 to 
135, programs describing procedures to be performed by 
objects in object-oriented programming) are ordinarily 
5 generated in the COM server. Both of them are loaded 
in a memory. A virtual address table (118, 120) is 
generated for each interface generated and provided to 
the EXE that has issued the request for generation of 
the instance. The generated addresses (124 to 129) of 

10 methods are contained in the virtual address table. 

The EXE uses this information to issues a call to each 
interface. Shown in FIG. 6 is an example in which the 
EXE (119) generates instances of two interfaces, 
Interface A (121) and Interface B (122), and uses 

15 methods in these interface. Specifically, Method AA, 

Method AB, Method AC, Method BA, Method BB, and Method 
BC (130 to 135) are used. 

When a code of the EXE calls Method AA, the 
address (124) of Method AA is first read from the 

20 virtual address table. Actually written in the virtual 
address table is the address of the Method AA code 
(130) generated as part Interface A in the COM server. 
The EXE code can call Method AA of Interface A by 
calling that address. 

25 FIG. 7 shows an organization of the memory of the 

software evaluation system according to the first 
embodiment. This organization differs from the one 

- 14 - 



shown in FIG. 6 in that a technique called VTable Patch 
(virtual address table patch) is used with a log 
acquisition code to redirect a method call. 

When log acquisition is initiated, a DLL (143) for 
5 VTable Patch is loaded in the memory. The DLL changes 
the addresses of the methods contained in the virtual 
address table (136, 138) to the addresses (145 to 150) 
of Method A' A, Method A 1 B, Method A'C, Method B'A, 
Method B 1 B, and Method B'C that are log acquisition 

10 codes in DLL. The codes Method A' A, Method A'B, Method 
A'C, Method B'A, Method B 1 B, and Method B'C (157 to 
162) in the DLL (143) perform logging and call the 
corresponding methods, Method AA, Method AB, Method AC, 
Method BA, Method BB, and Method BC (157 to 162) . 

15 FIG. 8A shows a flowchart of a process of VTable 

Patch in FIG. 7. FIG. 8B shows a flowchart of a log 
acquisition process. For simplicity, the figures show 
how the log acquisition code works with VTable Patch 
when the EXE calls Method AA in Interface A in the COM 

20 server. 

When the EXE (163) calls Method AA (166), a log 
acquisition code in the DLL (164) stores the module 
name/interface name/method name in the DLL (step S1802) , 
the call time, parameters used in the call in memory 
25 and stores the memory content pointed to by a pointer 
parameter in another memory (167 and step S803) . The 
DLL (164) then calls Method AA in the COM server (165) 



which is intended to be called (168 and step S804) . 
When Method process AA (169) in COM server (165) comes 
to an end and control returns to the DLL (170), the 
DLL (164) stores the return time and return value in the 
5 memory and the memory content pointed to by the pointer 
parameter at the return time in another memory (171) . 
The DLL then write the log information it stored in a 
file (172 and step S805) and returns the control to the 
EXE (163) as if Method AA in the COM server (165) ended 

10 in a conventional way (171) . 

FIG. 9 shows an internal configuration of the 
software evaluation system according to the first 
embodiment. Conventionally, an executable EXE (176) 
calls a method in the COM server 1 (17 9) or COM server 

15 2 (180) . In this method, in contrast, a log 

acquisition code called an API tracer (177) is embedded 
to generate a processing log (178) . The API tracer 
(177) operates according to a file (174) that describes 
definitions of functions in the COM server 1 (179) or 

20 COM server 2 (180) and a setting scenario (175) that 

specifies which method in which interface in which COM 
server in a virtual address table should be rewritten 
to obtain a log. 

As can be seen from the foregoing description, the 

25 log acquisition method according to the present 

embodiment for acquiring processing logs of software 
separated into a plurality of modules enables a 
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function/method call provided in a module to be logged 
without modifying the module itself, thereby reducing 
workload for obtaining the processing logs. 
Furthermore, logs generated can be acquired as 
5 chronological logs, facilitating analysis of the logs 
and consequently reducing the number of man-hours 
needed for identifying the cause of software failure. 
[Second Embodiment] 

A second embodiment of the present invention will 

10 be described below in which pointer parameter data in 

binary that cannot be acquired with conventional method. 

FIG. 10 shows an example of function definitions 
in a software evaluation system according to the second 
embodiment. The definitions are written in widely used 

15 IDL. A type library file that is tokenized IDL is used 
as a function definition file in the software 
evaluation system implementing the log acquisition 
method according to the second embodiment. 

FIG. 11 shows description written in IDL for 

20 acquiring pointer parameter data in a log form by 

specifying binary acquisition in pointer parameters in 
function definitions according to the present 
embodiment . 

In the definition of the function FuncBinidls, 
25 custom (PAT_PARAM_ATTR_ID, f, binid_is ( ) " ) is declared 

for long*lplParam (201), where PAT__PARAM_ATTR_I D (200) 
is an identifier used in IDL by the software evaluation 
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system. The definition of "binid_is ( ) " stores data of 
a size equal to the size of a data type (long type in 
this example) of this parameter on the basis of a 
pointer pointed to by this parameter in a log as binary 
5 data. 

In the definition of the function FuncSizels, 
custom (PAT_PARAM_ATTR_ID, "size_is (dwCount ) " ) is 
declared for int*lplParain (202) . The definition 
"size_is (dwCount) " specifies that the data size of this 

10 parameter is dwCount, which is its first parameter. 

"dwCount x the size of parameter data type (int type in 
this example)" of data are stored in the log as binary 
data from the pointer pointed to by this parameter. 
In the definition of the function FuncLengthls, 

15 custom (PAT_PARAM_ATTR_ID, "length_is (dwLength) " ) is 
declared for char*lpszParam (203) . The definition 
"length_is (dwLength) " specifies that this parameter 
should have data of size dwLength, which is its first 
parameter. "dwLength x the size of parameter data type 

20 (char in this example) " of data is stored as binary 
data in the log from the pointer pointed to by this 
parameter . 

In the definition of the function FuncBytesIs, 
custom (PAT_PARAM_ATTR_ID, "bytes_is (dwSi ze) " ) is 
25 declared for void*lpParam (204) . The definition 

"bytes_ is (dwSize) " specifies that the data size of this 
parameter is dwSize, which is the first parameter, in 
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bytes. The dwSize bytes of data are stored as binary 
data in the log from pointer pointed to by this 
parameter. 

In the definition of the function FuncBytesIs2 , 
5 custom (PAT_PARAM_ATTR_ID, M bytes_is ( 12 ) " ) is declared 
for void*lpParam (205). The definition "bytes_is ( 12 ) " 
specifies that this parameter should have data of 12 
bytes specified. Twelve bytes of data are stored in 
the log as binary data from the pointer pointed to by 

10 this parameter. 

FIG. 12 shows a flowchart of a process for 
acquiring a log in the software evaluation system 
according to the second embodiment when the functions 
are defined as shown in FIG. 11. 

15 When the process starts (step S1201), log 

acquisition is initiated and the module name, interface 
name, function/method name are stored in the HDD (step 
S1202) . Then the call time, a parameter, and, memory 
content pointed to by a pointer parameter are stored in 

20 the HDD (step S1203) . It is determined whether or not 
binary acquisition is specified in the function 
definitions (step S1204) and, if so, the memory size 
required for storing the data is calculated for each of 
the definitions (binid_is, size_is, length_is, and 

25 bytes_is) (step S1205) and the calculated size of the 
data in the memory pointed to by the pointer parameter 
is stored in the HDD (step S1206) . Then the original 



function is called (step S1207) . After returning from 
the function, the log acquisition code stores the 
return time, return value, and the content in memory 
pointed to by the pointer parameter in the HDD (step 
5 S1208) . Then it determines whether binary acquisition 
is specified in the function (step S1209) and, if so, 
calculates the memory size required for storing the 
data for each of the definitions (binid_is, size_is, 
length_is, and bytes_is) (step S1210) and stores the 
10 calculated size of the data in the memory pointed to by 
the pointer parameter in the HDD. Then the original 
function is called (step S1211) . This process will end 
when an end command is provided by the user (step 
S1212) . 

15 FIG. 13 shows log data acquired in accordance with 

the definitions in FIG. 11 in the software evaluation 
system according to the second embodiment. 

A log (210) excluding Data ID can be acquired when 
no binary acquisition is specified in function 

20 definitions. If binary acquisition is specified, 
Datald and binary data log (211) can be obtained. 
Compared with the log of FuncSizels acquired with 
specification of binary acquisition, the log of 
FuncSizels acquired without specification of binary 

25 acquisition provides only one piece of int-type data 
pointed to by the pointer parameter IpParam. However, 
the data actually points to 10 pieces of int-type data. 



Thus, 4 bytes (int-type data size) x 10 = 40 bytes in 
total can be acquired when binary acquisition is set. 

As can be seen from the forgoing description, the 
pointer parameter data that cannot otherwise be 
5 acquired can be acquired in binary in a logged manner 
by associating sizes with the pointer parameters 
according to the second embodiment. 
[Third Embodiment] 

A third embodiment will be described in which an 

10 unexported function such as a callback function is 
obtained as a log. 

FIG. 14 shows a description in IDL for acquiring 
functions such as a callback function that are not 
exported in function definitions according to the third 

1 5 embodiment . 

In the definition of the function SetCallBack, 
custom (PAT_PARAM_ATTR_ID, " f uncname_is ( FuncCallBack) ") 
is declared for DWORD pf nFuncCallBack (221). The 
function SetCallBack sets a callback function for a 

20 module. DWORD pf nFuncCallBAck is a parameter for 

setting the address of that callback function. The 
definition "funcname_is (FuncCallBack) " causes the log 
acquisition process to recognize a value provided to 
this parameter as the address of the FuncCallBack 

25 function (222) and replace it with an address for 

acquiring the log. The original value is stored for 
the purpose of calling the original callback function 
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during the acquisition of the log. This allows the log 
of the unexported callback function to be acquired. 

In the definition of the function GetFuncPointer, 
custom (PAT_PARAM_ATTR_ID, "f uncname_is (Funclnternal" ) 
5 is declared for DWORD pf nFuncInternal (223) . The 

function GetFuncPointer is a function for acquiring the 
pointer of a function in a module that has not been 
exported. DWORD pf nFuncInternal is a parameter for 
acquiring the pointer of an unexported function. The 

10 definition "funcname_is (Funclnternal) " causes the log 
acquisition process to recognize a value provided to 
this parameter as the address of the function 
Funclnternal (224) and replace it with an address for 
acquiring the log. The original value is stored for 

15 the purpose of calling the original callback function 

during the acquisition of the log. This allows the log 
of the function in the module that has not been 
exported to be acquired. 

The function GetFuncPointeArray (225) is a 

20 function for acquiring the address of an array of 

functions in the module that have not been exported and 
placing them in the structure FUNCPOINTERARRAY (220) . 
Here, custom ( PAT_PARAM_ATTR_ID, 

"funclnternal_is (Funclnternal 1-4)") is declared for 
25 the definition of each member of the FUNCPOINTERARRAY. 
The definition "funcname_is (Funclnternal 1-4)") causes 
the log acquisition process to recognize a value 
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provided to the members of the structure as the address 
of the functions Funclnternal 1- 4 (226) and replace it 
with an address for acquiring the log. The original 
value is stored for the purpose of calling the original, 
5 unexported function during the acquisition of the log. 
This allows the log of the unexported function in the 
module to be acquired. 

FIG. 15 shows a memory organization in the 
software evaluation system according to the third 

10 embodiment. This organization differs from the one 

shown in FIG. 3 in that codes for acquiring the log of 
hidden functions are added. FuncAD (231) in A. DLL is a 
function that has not been exported and therefore is 
not contained in the Import Address Table (230) . If 

15 funcname_is is defined for FuncAD, FuncCAD (232) is 
generated in C.DLL for acquiring the log and the 
address of FuncCAD is used for replacing a parameter 
value defined in funcname_is, which returns the address 
of FuncAD. 

20 FIG. 16 shows a flowchart of a process for 

acquiring a log in the software evaluation system 
according to the third embodiment when the functions 
are defined as shown in FIG. 14. 

When the process starts (step S1601) , the log 

25 acquisition is initiated and the module name, interface 
name, function/method name are stored in the HDD (step 
S1602) . Then the call time, a parameter, and contents 



pointed to by the pointer parameter are stored in the 
HDD (step S1603) . It is determined whether or not 
funcname^is is specified in the function definitions 
(step S1604) and, if so, the function definition 
5 defined in funcname_is is obtained form a function 
definition file and a code for log acquisition is 
generated according to that definition (step S1605) . 
Then the value defined in funcname_is is stored and 
replaced with the address of the log acquisition code 

10 generated (step S1606) . 

The original function is then called (step S1607). 
After returning from the function, the log acquisition 
code stores the return time, return value, and the 
content in memory pointed to by the pointer parameter 

15 in the HDD (step S1608) . Then it determines whether 
binary acquisition is specified in the function (step 
S1609) and, if so, obtains the definition of the 
function defined in funcname_is from a function 
definition file and generates a code for log 

20 acquisition according to the definition (step S1610) . 
Then it stores the value defined in funcname_is and 
replaces it with the address of the log acquisition 
code generated (step S1611) . This process will end 
when an end command is issued by the user (step S1612) . 

25 Once the parameter set in funcname_is has been 

replaced with the address of the log acquisition code 
generated, the original function called by using that 
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address is treated in a similar manner in which an 
ordinary log is treated (that is, the generated log 
acquisition code calls an unexported function, causes 
it to be executed, receives the result of execution, 
5 passes the result to the original function, and logs 
information concerning the call to the unexported 
function and information concerning the reception of 
the results of the execution) . 

FIG. 17 shows log data acquired in the software 

10 evaluation system according to the third embodiment 

when the definitions shown in FIG. 14 are not provided. 
No log of unexported internal functions can be acquired 
if log acquisition for them is not set in a function 
definition file. 

15 FIG. 18 shows log data acquired from the 

definitions shown in FIG. 14 in the software evaluation 
system according to the third embodiment. The logs of 
unexported functions, such as SetCallBack, Funclnternal , 
and Funclnternal4 can be acquired because settings for 

20 acquiring the callback functions and unexported 
internal functions are provided in a function 
definition file. 

Thus, the third embodiment has the advantage that 
the logs of unexported functions which cannot otherwise 

25 be acquired can be acquired. 
[ Fourth Embodiment ] 
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A fourth embodiment will be described in which a 
log of a variable-length array parameter, which cannot 
be acquired with conventional methods, is obtained. 

FIG. 19 shows a description in IDL for acquiring a 
5 log of a variable-length array parameter according to 
the fourth embodiment. 

In the definition of the function FuncArrayls, 
custom ( PAT_PARAM_ATTR_ID, "array__is (dwCount) " ) is 
declared for int*lpnParam (240) . The definition 

10 "array_is(dwCount)" specifies that this pointer 
parameter is an int-type array and the number of 
elements of the array is equal to dwCount, which is the 
first parameter. The pointer pointed to by this 
pointer parameter is treated as an array of dwCount 

15 number of int-type data elements and the data is stored 
in the log. 

FIG. 20 shows a flowchart of a process for 
acquiring a log in the software evaluation system when 
a function is defined as shown in FIG. 19. 

20 When the process starts (step S2001) , the log 

acquisition is initiated and the module name, interface 
name, function/method name are stored in the HDD (step 
S2002) . Then it is determined whether or not variable- 
length array acquisition (array_is) is set in the 

25 function definitions (step S2003) . If so, the 

parameter defined by the pointer parameter is treated 
as definition of an array (step S2004) and the call 
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time, parameter, and the content pointed to by the 
pointer parameter are stored in the HDD (step S2005) . 
Then the original function is' called (step S2006) . 
After returning from the function, the log acquisition 
5 code determines whether or not variable-length array 
acquisition (array_is) is set in the function 
definitions (step S2007) and if so, the parameter 
defined by the pointer parameter is treated as 
definition of an array (step S2008) and the return time, 

10 the return value, and the memory content pointed to by 
the pointer parameter in the HDD (step S2009) . The 
process will end when an end command is provided by the 
user (step S2010) . 

FIG. 21 shows log data (250) acquired without the 

15 definition shown in FIG. 19 and log data (251) acquired 
with the definitions shown in FIG. 19 in the software 
evaluation system according to the fourth embodiment. 
When the definitions are not made in the function 
definition file, only the first data for each parameter 

20 is acquired in log data (250) because pointer 

parameters cannot be treated as an array. In contrast, 
when the definitions are not made in the function 
definition file, the pointer parameters are treated as 
arrays and therefore all data in the arrays are 

25 obtained in log data (251) . 

In this way, the fourth embodiment provides the 
advantage that a log of variable-length parameters, 
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which is a function log that cannot be obtained with 
conventional methods. 
[Fifth Embodiment] 

A fifth embodiment will be described in which a 
5 log of a function that cannot be acquired with 
conventional methods, is acquired. 

FIG. 22 shows an example of a function which is 
used in the software evaluation system according to the 
fifth embodiment and for which parameters cannot be 

10 obtained with conventional function definitions. 

Three structures, STRUCTSIZE1, STRUCTSIZE2, and 
STRUCTSIZE3, are defined. The DWORD dwSize member of 
each structure should contain the size of that 
structure. The first parameter dwKind of the 

15 FuncGetData function should indicate the pointer of one 
of the three structures that is passed to the second 
parameter lpBuf. The FuncGetData function treats lpBuf 
as the pointer to STRUCTSIZE1 if the first parameter is 
1, or as the pointer to STRUCTSIZE2 if the first 

20 parameter is 2, or as the pointer to STRUICTSIZE3 if 
the first parameter is 3. If the FuncGetData were 
defined with a conventional function definition, lpBuf 
would be a void-type pointer and consequently no data 
can be obtained. 

25 FIG. 23 shows how memory is used by each of the 

structures STRUCTSIZE1, STRUCTSIZE2 , and STRUCTSIZE3 in 
FIG. 22. The STRUCTSIZE 1 (260) has a member DWORD 
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dwSize (261) at offset 0x000, DWORD dwParaml (262) at 
0x0004, DWORD dwParam2 (263) at 0x0008, and DWORD 
dwParam3 (264) at OxOOOC. The structure STRUCTSIZE 2 
(265) has DWORD dwSize and DWORD dwParaml - DWORD 
5 dwParam3 (266-269) at the same offsets as those for the 
members of STRUCTSIZE1 and, in addition, DWORD dwParam4 
(270) at 0x0010. STRUCTSIZE3 (271) has DWORD dwSize 
and DWORD dwParaml - DWORD dwParam4 (272-27 6) at the 
same offsets as the members of STRUCSIZE2 and, in 

10 addition, DWORD dwParam5 (277) at 0x0014. As just 
described, the memory locations of the dwSize - 
dwParam4 of STRUCTSIZE3 are the same as those of 
STRUCTSIZE2 and the memory locations of the dwSize - 
dwParam3 are the same as those of STRUCTSIZE1. 

15 FIG. 24 shows a description in IDL for acquiring a 

log of parameters of the function as shown in FIG. 22 
in the software evaluation system according to the 
fifth embodiment. 

The separate structures STRUCTSIZE1, STRUCTSIZE2, 

20 and STRUCTSIZE 3 in the original function are defined 
as a single structure (291) . The definition is the 
same as that of STRUCSIZE3 because STRUCTSIZE3 has the 
memory locations that overlap the memory locations of 
STRUCTSIZE1 and STRUCTSIZE2. [custom ( PAT_PARAM_ID, 

25 "structsize_is ( ) 11 ) is set for the DWORD dwSize member 
of the this structure, which indicates the size of the 
structure (290) . This allows the log acquisition 
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process to obtain the size of the structure during data 
analysis of the structure. The second parameter lpBuf 
in the FuncGetData function is defined as the 
STRUCTSIZE type (292) . This causes the parameter is 
5 treated as the STRUCTSIZE type when it is stored as a 
log. If this technique were not used and a description 
were provided in a function definition file in such a 
manner as to obtain data on STRUCTSIZE3, a call to 
GetFuncData with dwKind =1 or 2 would cause an memory 

10 exception because data on STRUCTURESIZE1 or STRUCTSIZE2 
exists and a log acquisition process would attempt to 
acquire the log of dwParam3 or dwParam4 data. 

FIG. 25 shows a flowchart of a process for 
acquiring a log in the software evaluation system 

15 according to the fifth embodiment when the function are 
defined as shown in FIG. 24. 

When the process starts (step S2501) , log 
acquisition is initiated and the module name, interface 
name, function/method names are stored in the HDD (step 

20 S2502) . Then it is determined whether or not the size 
of the structure (structsize_is) of the structure is 
specified in the function definitions (step S2503) . If 
so, set structure parameter data of the size defined in 
the size specification ( structsize__is ) is analyzed 

25 (step S2504). Then, the call time, parameter, and 

memory content pointed to by a pointer parameter are 
stored in the HDD (step S2505) . Then the original 
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function is called (step S2506) . After returning from 
the function, the process determines whether or not the 
size of the structure (structsize_is) of the structure 
is specified in the function definitions (step S2507) 
5 and if so, the set structure parameter data of the size 
defined in the size specification ( structsize_is ) is 
analyzed (step S2508) . Then the return time, return 
value, and the memory content pointed by the pointer 
parameter are stored in the HDD (step S2509) . The 

10 process will end when an end command is provided by the 
user (step S2510) . 

FIG. 26 shows details of the structure parameter 
analysis performed in FIG. 25, on the basis of the 
memory locations. 

15 When GetFuncData is used in an actual program with 

dwKind =1, the STRUCTSIZE1 structure (300) is used and 
the members (301-304) use memory as shown in FIG. 25. 
If the function definition shown in FIG. 24 has been 
provided, it is recognized as the STRUCTSIZE structure 

20 (305) in the software evaluation system and the members 
(306-311) may use memory as shown. If size 
specification (structsize_is) is set, the value of 
dwSize can be checked to know that the size of the 
structure is dwSize bytes and the dwSize bytes of data 

25 (302) is obtained as a log from STRUCTSIZE structure. 

FIG. 27 shows log data obtained through the user 
of the definitions shown in FIG. 24 in the software 



evaluation system according to the fifth embodiment. 
Data on the structures that would be void* and only 
pointers would be able to be acquired with an ordinary 
function definition can be acquired as logs according 
5 to the types of the structures used. 

Thus, the fifth embodiment has the advantage that 
a log of parameters that cannot be acquired with 
conventional methods can be acquired. 
[Sixth Embodiment] 

10 FIG. 28 shows an example of the functions that are 

used in the software evaluation system according to a 
sixth embodiment and of which parameters cannot be 
obtained with a conventional function definition. 

Three structures STRUCTKIND1, STRUCTKIND2, and 

15 STRUCTKIND3 are defined. The first parameter dwKind of 
the FuncGetData function should indicates the pointer 
of one of the three structures that is passed to the 
second parameter lpBuf . The FuncGetData function 
treats lpBuf as the pointer to STRUCTKIND1 if the first 

20 parameter is 1, or as the pointer to STRUCTKIND2 if the 
first parameter is 2, or as the pointer to STRUICTKIND3 
if the first parameter is 3. If the FuncGetData were 
defined with a conventional function definition, lpBuf 
would be a void-type pointer and consequently no data 

25 can be obtained. 

FIG. 29 shows how memory is used by each of the 
structures STRUCTKIND1, STRUCTKIND2, and STRUCTKIND3. 
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The STRUCTKIND1 (330) has a member char chParam (331) 
at offset 0x0000, DWORD dwParam (332) at 0x0001, and 
short shParam (333) at 0x0005. The structure 
STRUCTKIND2 (334) has a member short shParam (335) at 
5 offset 0x000, DWORD dwParam (336) at 0x0002, and char 
chParam (337) at 0x0006. The structure STRUCTKIND3 
(338) has a member char chParam (339) at 0x0000, short 
shParam (340) at 0x0001, DWORD dwParam (341) at 0x0003, 
long lParam (342) at 0x0007, and int nParam at OxOOOB. 

10 The structures include no size information and memory 
organizations for structure data differs from one 
structure to another. Therefore, the method described 
with respect to the fifth embodiment cannot be used. 

FIG. 30 shows a description in IDL for acquiring a 

15 log of the parameters of the function shown in FIG. 28 
in the software evaluation system according to the 
sixth embodiment. 

The structures are defined with a conventional 
method . [ custum ( PAT_PARAM_ID, 

20 "structkind_is (dwKind: 1 : STRUCTKIND1* , 2 : STRUCTKIND2* , 
3 : STRUCTKIND3*) ") ] is set for the second parameter 
void*lpBuf of the FuncGetData function. This causes 
the lpBuf to be treated as the STRUCTKIND1* data type 
if the value of the first parameter dwKind is 1, or as 

25 STRUCTKIND2* if the value is 2, or as STRUCTKIND3* if 
the value is 3 and stored as a log. 
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FIG. 31 shows a flowchart of a process for 
acquiring a log in the software evaluation system 
according to the sixth embodiment when the function is 
defined as shown in FIG. 30. 
5 When the process starts (step S3101) , log 

acquisition is initiated and the module name, interface 
name, function/method names are stored in memory (step 
S3102). Then it is determined whether or not structure 
type specification (structkind_is) is set in the 

10 function definition (step S3103) . If it is set, the 
set structure parameter data is analyzed as the data 
type defined in the type specification ( struct kind_is ) 
(step S3104). Then the call time, parameter, and 
memory content pointed to by a pointer parameter are 

15 stored in the memory (step S3105) . Then the original 
function is called (step S3106) . After returning from 
the function, the process determines whether or not 
structure type specification ( struct kind_is ) is set in 
the function definition (step S3107). If it is set, 

20 the set structure parameter data is analyzed as the 
data type defined in the type specification 
( struct kind_is) (step S3108) . Then the return time, 
return value, and the memory content pointed to by the 
pointer parameter is stored in the memory (step S3109) . 

25 The process will end when an end command is provided by 
the user (step S3110) . 
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FIG. 32 shows log data acquired with the 
definitions shown in FIG. 30 according to the sixth 
embodiment. Data on the structures that would be void* 
and only pointers would be able to be acquired with an 
5 ordinary function definition can be acquired as logs 
according to the types of the structures used. 

Thus, the sixth embodiment provides the advantage 
that a log of parameters that cannot be acquired with 
conventional method can be acquired. 
10 [Seventh Embodiment] 

A user interface for making settings for log 
acquisition and a process performed according to 
information set through the user interface in a seventh 
embodiment. FIG. 33 shows a user interface setting 
15 functions/methods for initiating log acquisition 
according to the seventh embodiment. 

The user interface includes a dropdown list (352, 
353) of modules/interfaces (350) from which a user can 
select a module/interface the log of which is to be 
20 acquired and a dropdown list (354, 355) of 

functions/methods (351) exported in the selected 
module/interface, from which the user can select a 
function/method to be set as a log acquisition trigger. 
FIG. 34 shows a flowchart of a process for 
25 acquiring a log according to settings in the interface 
shown in FIG. 33 in the software evaluation system 
according to the seventh embodiment. 



When the process is started (step S3401) , the log 
acquisition code determines whether or not a called 
function/method is set as a log acquisition trigger 
(step S3402) . If it matches the log acquisition 
5 trigger, the code starts log acquisition and stores the 
module name, interface name, function/method name in 
the HDD (step S3403) . Then the log acquisition code 
stores the call time, parameter, and the memory content 
pointed by a pointer parameter in the HDD (step S3404) 

10 and calls the original function/method (step S3405) . 
When returning from the function/method, the log 
acquisition code stores the return time, the return 
value, and the memory content pointed to by the pointer 
parameter in the HDD (step S3406) . The process 

15 continues until an end command is provided by the user 
(step S3407) without making determination as to the log 
acquisition initiation trigger. 

As can be seen from the forgoing description, the 
seventh embodiment provides the advantage that it 

20 allows the user to select any of functions/methods the 
log of which is to be acquired, thereby facilitating 
log analysis. 
[Eighth Embodiment ] 

While it allows a user to select any 

25 function/method the log of which is to be acquired 

according to the seventh embodiment, it allows the user 
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to select any function/method the log of which is to be 
stopped will be described in an eighth embodiment, 

FIG. 35 shows a user interface for setting a 
function/method the log of which is to be stopped 
5 according to the eighth embodiment. 

The user interface includes a dropdown list (358, 
359) of modules/interfaces (356) from which a user can 
select a module/interface the log of which is to be 
acquired. It also includes a dropdown list (360, 361) 
10 of functions/methods (357) exported in the selected 
module/interface, from which the user can select a 
function/method to be set as a log acquisition stop 
trigger. 

FIG. 36 shows a flowchart of a process for 
15 acquiring a log in accordance with settings in the 

interface shown in FIG. 35 in the software evaluation 
system according to the eighth embodiment. 

When the process is started (step S3601) , log 
acquisition is started and the module name, interface 
20 name, function/method name is stored in the HDD (step S 
3602) . The log acquisition code then stores the call 
time, a parameter, and the memory content pointed to by 
a pointer parameter in the HDD (step S3603) and calls 
the original function/method (step S3604) . When 
25 returning from the function/method, the log acquisition 
code stores the return time, the return value, and the 
memory content pointed to by the pointer parameter in 
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the HDD (step S3605) . Then it determines whether or 
not the called function/method is set as a log 
acquisition stop trigger (step S3606) . If it matches 
the log acquisition stop trigger, the log acquisition 
5 process end (step S3607) . If it does not match the log 
acquisition stop trigger, the process will end in 
response to an end command from the user (step S3606) . 

Thus, the eighth embodiment provides the advantage 
that the user can stop acquisition of the log of any 

10 set function/method and acquire only the log that the 
user wants to, thereby facilitating log analysis. 
[Ninth Embodiment] 

While the user interfaces described with respect 
to the seventh and eighth embodiments allow the user to 

15 select a function/method to start/stop acquisition of 

its log, log acquisition may be started/stopped only if 
any function/method selected by the user is terminated 
by an error. 

FIG . 37 shows a log acquisition start/stop user 
20 interface having an option added for using the trigger 
function (log acquisition start/stop function) only if 
the function/method is terminated by an error according 
to a ninth embodiment. This user interface can be 
applied to both interfaces shown in FIGS. 33 and 35. 
25 The user interface includes a dropdown list (364, 

365) of modules/interfaces (362) whose log can be 
acquired and from which a user can select a 
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module/interface to set, a dropdown list (366, 367) of 
functions/methods (363) exported in the selected 
module/interface from which the user can select a 
function/method to set, and a check box (368) for 
5 activating a trigger function only if the 
function/method is terminated by an error. 

FIG. 38 shows error definitions for 
functions/methods according to the ninth embodiment. 
The error definitions in the present embodiment take 

10 the form of files. Each file contains a parameter and 
return value of each function/method and its defined 
error condition. 

FIG. 39 shows a flowchart of a process for 
acquiring a log in the software evaluation system 

15 according to the present embodiment. In this process, 
the function of using a trigger only when a log 
acquisition starts and an error occurs is specified in 
accordance with settings made in the interface shown in 
FIG. 37. 

20 When the process is started (step S3901) , the log 

acquisition code determines whether or not a 
function/method is set as a log acquisition trigger 
(step S3902) . If it is set as the log acquisition 
initiation trigger, the log acquisition code 

25 temporarily stores the module name, interface name, 
function/method name in memory (step S3903) . 
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The log acquisition code then temporarily stores 
the call time, a parameter, and the memory content 
pointed to by a pointer parameter in memory (step 
S3904) and calls the original function/method (step 
5 S3905) . After returning from the method, the log 

acquisition code temporarily stores the return time, a 
return value, and a content pointed to by the pointer 
parameter in memory (step S3906) . 

Then the log acquisition code determines whether 

10 or not the log acquisition initiation trigger should be 
used only if an error occurs (step S3907) and, if so, 
determines whether or not the function/method has 
resulted in an error (step S3908) . If no error has 
occurred, the log acquisition code discards the log it 

15 has temporarily stored in the memory (step S3909) and 
returns to the top of the process. On the other hand, 
if the function/method has resulted in an error, the 
code stores the log it has temporarily stored in the 
memory into the HDD (step S3910) and continues the 

20 ordinary log acquisition process (step S3911) . The 

process continues until an end command is provided from 
the user (step S3912) . 

FIG. 40 shows details of the ordinary log 
acquisition process shown at step S3911 in FIG. 39. 

25 When the process is started (step S4001), log 

acquisition starts and the module name, interface name, 
function/method name is stored in the HDD (step S4002) . 



Then the log acquisition code stores the call time, a 
parameter, and the memory content pointed to by a 
pointer parameter in the HDD (step S4003) and calls the 
original function/method (step S4004) . After returning 
5 from the function/method, the log acquisition code 
stores the return time, return value, and memory 
content pointed to by the pointer parameter in the HDD 
(step S4005) . 

FIG. 41 shows a flowchart of a process for 

10 obtaining a log in the software evaluation system 

according to the present embodiment. In this process, 
the function of using a trigger only when a log 
acquisition stops and an error occurs is specified in 
accordance with settings in the interface shown in FIG . 

15 37. 

When the process is started (step S4101) , log 
acquisition is started and the module name, interface 
name, function/method name are stored in the HDD (step 
S4102) . The log acquisition code stores the call time, 

20 a parameter, and the memory content pointed to by a 

pointer parameter in the HDD (step S4103) and calls the 
original function/method (step S4104) . After returning 
from the function/method, the log acquisition code 
stores the return time, return value, and memory 

25 content pointed to by the pointer parameter in the HDD 
(step S4105) . It then determines whether or not the 
called function/method is set as a log acquisition stop 
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trigger (step S4106) . If it matches the log 
acquisition stop trigger, it determines whether or not 
the log acquisition stop trigger should be used only if 
an error occurs (step S4107) and, if so, it determines 
5 whether or not the function/method has resulted in an 
error (step S4108) . If it has resulted in an error, 
the log acquisition process ends (step S4109) . The 
process also ends when an end command is provided by 
the user (step S4110) . 

10 Thus, the ninth embodiment provides the advantage 

that log acquisition can be started or stopped when an 
error occurs in a given function/method and the user 
can acquired the log that the user wants to obtain, 
thereby facilitating log analysis. 

15 [Tenth Embodiment] 

While selectable functions/methods are arranged in 
a predetermined order in the user interfaces in the 
seventh to ninth embodiments, they may be displayed in 
a tree view that allows a user to readily determine the 

20 relationships among interfaces and methods. 

FIG. 42 shows a user interface that provides a 
tree view of interfaces and methods according to a 
tenth embodiment . 

The user interface has a view (380) for displaying 

25 interfaces and methods in tree form. When a user 
checks an interface, InterfaceA (381), all methods 
MethodAA, MethodAB, and MethodAC (382-384) in the 



interface are selected as targets for log acquisition. 
When the user unchecks an interface InterfaceB (385), 
all method MethodBA, MethodBB, and Method BC (385-388) 
in the interface are deselected and excluded from the 
5 target for log acquisition. 

FIG. 43 shows a flowchart of a process for 
acquiring a log in the software evaluation system 
according to the tenth embodiment when targets for log 
acquisition are selected as shown in FIG. 42. 

10 Once the process has been started (step S4301) , 

the log acquisition code determines, each time a call 
to a method in an interface is made, whether or not the 
interface associated with the method is a target for 
log acquisition (step 4302) . If it is a target for log 

15 acquisition, then the log acquisition code stores the 

module name, interface name, and method name in the HDD 
(step S4303) . 

Then the log acquisition code stores the call time, 
parameter, memory content pointed to by a pointer 

20 parameter in the HDD (step S4304) and calls the 

original method (step S4305) . After returning from the 
method, the log acquisition code stores the return time, 
return value, and memory content pointed to by the 
pointer parameter in the HDD (step S4306) . The process 

25 continues until an end command is provided by the user 
(step S4307) . 
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Thus, the user can more readily know the 
relationship between interfaces and methods and readily 
selects an interface to obtain its log, thereby 
facilitating acquisition of the desired log. 
5 [Eleventh Embodiment] 

While all the method in an interface are selected 
in the seventh to tenth embodiments, individual 
method (s) may be independently selected. 

FIG. 44 shows a user interface that provides a 
10 tree view of interfaces and methods according to an 

eleventh embodiment. This user interface is the same 
as the one shown in FIG. 42 but the method for 
selecting from among them is different. 

The user interface includes a view (389) for 
15 displaying interfaces and methods in tree form. A user 
can check any of the methods MethodAA (391), MethodAC 
(393), MethodBA (395), and uncheck any of the methods 
MethodAB (392), MethodBB (396), Method BC (397) to 
select only one or more methods that are left checked 
20 in interfaces InterfaceA (210), InterfaceB (394) as 

targets of log acquisition, rather than all the methods 
in each interfaces. 

FIG. 45 shows a flowchart of a process for 
acquiring a log in the software evaluation system 
25 according to the eleventh embodiment when targets of 
log acquisition are selected as shown in FIG. 44. 
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Once the process has been started (step S4501), 
the log acquisition code determines, each time a call 
to a method in an interface is made, whether or not any 
of the methods associated with the interface are 
5 targets for log acquisition (step S4502) . If it any of 
them are targets for log acquisition, then the log 
acquisition code stores the module name, interface name, 
and method name(s) in the HDD (step S4503) . The process 
(step S4504 to S4507) is the same as the one shown in 
10 Fig . 43 according to the tenth embodiment . 

Thus, this embodiment provides the advantage that 
the user can readily select an individual method or 
methods to acquire the log of them, rather than an 
interface, which is a larger unit. Consequently, the 
15 user can readily acquire his/her desired log. 
[Twelfth Embodiment] 

While an acquired log is stored in a given 
location in the HDD in the embodiments described above, 
a log may be stored on a date-by-date basis in order to 
20 facilitate log analysis. 

FIG. 46 shows a flowchart of a process for storing 
logs separated on a date-by-date basis. 

When the process is started (step S4601) , log 
acquisition is initiated and the module name, interface 
25 name, function/method name are stored in memory (step 
S4602) . 
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The log acquisition code then stores the call date 
and time, parameter, and a memory content pointed to by 
a pointer in memory (step S4603) and calls the original 
function/method (step S4604). After returning from the 
5 function/method, the log acquisition code return date 
and time, return value, memory content pointed to by 
the pointer parameter in memory (step S4605) . Then it 
determines whether or not the date of the return of the 
called function/method differs from the return date 

10 previously stored (step S4606) . If the date differs 

from the previous return date, the log acquisition code 
generates a new log file and stores the log in that 
file (step S4607) . On the other hand, if they are the 
same, the log acquisition code stores the log in the 

15 existing log file (step S4608) . This process end 

(S4 610) when an end command is provided by the user 
(step S4609) . 

Thus, this embodiment provides the advantage that 
it allows the user to acquire logs on a date-by-date 
20 basis, thereby facilitating log analysis. 
[Thirteenth Embodiment] 

While logs are stored on a date-by-date basis in 
the twelfth embodiment described above, logs can be 
stored separately according to the size or number of 
25 the logs. 
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FIG . 47 shows a flowchart of a process for 
separately storing logs according to the size or the 
number of the logs . 

When the process is started (step S4701) , log 
5 acquisition starts and the module name, interface name, 
and function/method name are stored in memory (step 
S4702) . The log acquisition code then stores the call 
time, parameter, and the memory content pointed to by a 
pointer parameter in memory (step S4703) and calls the 

10 original function/method (step S4704) . After returning 
from the function/method, the log acquisition code 
stores the return time, the return value, and the 
memory content pointed to by the pointer parameter in 
memory (step S4705) . Then it determines whether 

15 storing the new log data in an existing log file causes 
the size of the file or the number of logs in the file 
to exceed to a predetermined value (step S4706) . 

If the size or the number of the logs exceeds the 
predetermined value, the log acquisition code generates 

20 a new log file and stores the log in that file ( step 

S4707). Otherwise, if not exceed it stores the log in 
the existing log file (step S4708) . If the log 
acquisition code generates a new log file, it 
determines whether or not a ring buffer is used and the 

25 number of log files generated is more than two (step 
S4709) . If so, it deletes the oldest log file (step 
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4710) . This process ends (step S4712) when an end 
command is provided from the user (step S4711) . 

Thus, the user can acquire size-controlled, 
generated files and a predetermined number of generated 
5 logs. The present embodiment therefore has the 
advantage that it provides more manageable logs. 
Furthermore, using a ring buffer can limit the load 
placed by the software evaluation system on the 
resources of the PC, enabling stable log acquisition. 

10 [Fourteenth Embodiment] 

FIG. 4 8 schematically shows memory in which a 
predetermined number of acquired logs are stored. 

N log storage areas (398) are provided for storing 
a predetermined number of logs. Each log storage area 

15 stores a log of functions/methods. The information is 
stored includes the module name, interface name, 
function/method name, call time, parameter data at the 
call time, the end time, parameter data at the end time, 
and return value data (399) . The information has a 

20 variable size. Log data is stored in the. memory areas 
in order, from log storage memory area 1 to log storage 
memory area n. When the areas are exhausted, the logs 
are overwritten, starting from log storage memory are 1. 
FIG. 49 shows a flowchart of a process for 

25 acquiring logs and storing a predetermined number of 
acquired logs in the memory. 
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When the process is started (step S4901) , a 
variable x indicating the location of a log storage 
area is initialized to 1 (step S4902) . Then log 
acquisition is started and the module name, interface 
5 name, function/method name are stored in the log 
storage memory area x (step S4903) . 

The log acquisition code then stores the call time, 
a parameter, and the memory content pointed to by a 
pointer parameter in log storage memory area x (step 

10 S4904) and calls the original method/function (step 

S4 905) . After returning from the function/method, the 
log acquisition code stores the return time, the return 
value, and the memory content pointed to by the pointer 
parameter in log storage memory area x (step S4906) . 

15 Then it adds 1 to the variable x that indicates the 

location of a log storage memory area (step S4907) and 
determines whether x exceeds the number n of the log 
storage memory areas (step S4908) . 

If x is larger than n, it assigns 1 to x so that 

20 the log storage memory areas are reused from the top 
log storage memory area (step S4909) . Then it 
determines whether or not a ring buffer is to be used 
(step S4910) . If not, the log acquisition code stores 
all log data in the memory into a log file (step S4911) 

25 and deletes all the log data from the memory (step 
S4912) . This process ends (step S4914) when an end 
command is provided from the user (step S4913) . 
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Thus, memory usage can be limited ad load placed 
by the software evaluation system on the resources of 
the PC can be minimized, enabling stable log 
acquisition. 
5 [Other Embodiments] 

The present invention may be applied to a system 
consisting of a plurality of devices (for example, a 
host computer, interface devices, a reader, and a 
printer) or a standalone apparatus (for example a 
10 copying machine or facsimile machine. 

The object of the present invention can also be 
achieved by providing a storage medium containing a 
program code of software that implements the functions 
of the embodiments described above to a system or an 
15 apparatus and causes to a computer (or CPU or MPU) of 
the system or the apparatus to read and execute the 
program code stored on the storage medium. 

In that case, the program code read from the 
storage medium implements the functions of the 
20 embodiments described above and the storage medium on 
which the program code is stored constitutes the 
present invention . 

The storage medium for providing the program code 
may be a floppy® disk, disk, hard disk, optical disk, 
25 magneto-optical disk, CD-ROM, CD-R, magnetic tape, 
nonvolatile memory card, or ROM. 
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The present invention includes not only 
implementations in which the features of the 
embodiments described above are implemented by a 
computer reading and executing the program code but 
5 also implementations in which an OS (operating system) 
or the like running on a computer executes all or part 
of the actual processing to implement the features of 
the embodiments described above according to 
instructions in the program code. 

10 Furthermore, the present invention includes cases 

where the program code read from the storage medium is 
written into an expansion board inserted into a 
computer or memory provided in a expansion unit 
connected to a computer and a CPU or other processor 

15 provided in the expansion board or expansion unit 

executes all or part of the actual processing and the 
processing implements the features of the embodiments 
described above. 

As described above, the present invention allows 

20 processing logs of software divided into a plurality of 
modules to be readily acquired and reduces the man- 
hours need to analyze the cause of software failure. 

As many apparently widely different embodiments of 
the present invention can be made without departing 

25 from the spirit and scope thereof, it is to be 

understood that the invention is not limited to the 
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specific embodiments thereof except as defined in the 
claims . 
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